Skip to content

Release automatically when a version bump is merged to master - #132

Open
conatus wants to merge 3 commits into
masterfrom
release-on-version-bump
Open

conatus wants to merge 3 commits into
masterfrom
release-on-version-bump

Conversation

@conatus

@conatus conatus commented Oct 23, 2026

Copy link
Copy Markdown
Member

Why

Releases needed a manual tag push after merging the version bump. Merging a PR that bumps the version should be enough to ship it.

How

  • release-plugin.yml now runs on pushes to master (and "Run workflow"), not on tag pushes.
  • A check job runs the new scripts/check-version.sh, which fails if join.php, readme.txt and index.tsx disagree on the version or readme.txt has no changelog entry for it. It then looks for a tag with that version. If the tag exists, every other job is skipped.
  • If not, the php, Jest and e2e tests run as before, then build, deploy to WordPress.org, push the tag on the merged commit, and create the GitHub Release.
  • The version bump stays a deliberate commit in the PR. bump-version.sh and the readme no longer tell you to tag.
  • check-version.sh has tests in scripts/check-version.test.sh, run by a new Script Tests workflow.

Manual tag pushes no longer release. I dropped that trigger instead of keeping it as a fallback: a hand-pushed tag racing the master run could deploy twice, and a hand-made tag makes the check skip that version. Re-running the failed jobs is the fallback.

The tag is pushed with GITHUB_TOKEN, so it starts no other workflow runs. This workflow no longer listens for tags either way.

Test plan

  • Script Tests passes on this PR
  • After merging, the release run on master shows "Tag 1.4.44 already exists" and skips the tests and the release job
  • Next version bump PR: after merging, the run tests, deploys, creates the tag on the merge commit and creates the GitHub Release with notes
  • The new version appears on wordpress.org/plugins/common-knowledge-join-flow

Watch out for

  • Failure part way through. The tag is created only after the SVN deploy succeeds. If tagging or the GitHub Release fails, use "Re-run failed jobs". The 10up action skips the commit when the SVN tag already exists, and the tag step skips an existing tag. Don't re-run the whole workflow once the tag exists: the check will see it and skip, leaving the GitHub Release to be created by hand.
  • Bad version data blocks master. A mismatch or a missing changelog entry fails the master run before anything ships. Fix it in a follow-up PR.
  • Order with JOIN-150 Add optional income guidance to the membership step #125 (1.4.45). If JOIN-150 Add optional income guidance to the membership step #125 merges after this, 1.4.45 releases on merge. If it merges first and is tagged by hand, this does nothing for 1.4.45. If it merges first and isn't tagged, merging this releases 1.4.45.
  • Runs are serialised (concurrency: release-plugin). Pending runs can be superseded, but the newest run checks the latest version, so nothing is lost.
  • Verified with actionlint 1.7.12 (with shellcheck). The real release path can't be run before merging.

🤖 Generated with Claude Code

@conatus
conatus requested a review from joaquimds October 26, 2026 21:18
@conatus conatus self-assigned this Oct 26, 2026
@conatus

conatus commented Oct 26, 2026

Copy link
Copy Markdown
Member Author

@joaquimds

This is a big enough engineering change that I think it would be good for you to do a manual review. Thank you!

Comment thread readme.md

The workflow fails before releasing if the version in `join.php`, the `Stable tag:` in `readme.txt` and the `release:` in `packages/join-flow/src/index.tsx` disagree, or if `readme.txt` has no changelog entry for the version. Run `./scripts/check-version.sh` to check this locally.

Don't push tags by hand: a tag push no longer triggers a release, and a hand-made tag would make the workflow skip that version. If a release fails, use "Re-run failed jobs" on the run. Re-running is safe: the deploy skips a version already on WordPress.org, and the tag is only created after the deploy succeeds.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't write this kind of documentation which says a change occurred. Documentation should detail the current status, not some legacy status that people don't need to know about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant